I CERTIFICATE OF MAILING 

2 

3 U.S. PATENT APPLICATION FOR A: 

4 

5 MODELING TOOL FOR ELECTRONIC SERVICES AND ASSOCIATED METHODS 

6 
7 

8 a 

9 £ 

10 

II W INVENTORS: 

12 L FABIO CASATI 

13 H MING-CHI EN SHAN 

14 p S MEHMET SAYAL 

15 £ 

16 fs 

17 rf 

18 
19 
20 
21 

22 
23 
24 
25 

26 

27 "Express Mail" mailing label number. 

28 Date of Deposit <a iM f t^?^/ 

29 I hereby certify that this papir or fee is being deposited with the United States Postal Service "Express Mail Post Office to 

30 Addressee" services under 37 C.F.R. 1 .10 on the date indicated above and is addressed to the Commissioner of Patents 

3 1 and Trademarks, Washington, D.C. 2023,1 . 

32 Typed Name of Person Mailing Paper 05/Fee: EUGENE H. VALET 

33 

34 Signature: 




-0- 



1 (1) TITLE 

2 MODELING TOOL FOR ELECTRONIC SERVICES AND ASSOCIATED METHODS 

3 (2) CROSS-REFERENCE TO RELATED APPLICATIONS 

4 This application is related to U.S. Patent Application Serial No. (attorney docket 

5 1 0008278-1 ), by the same inventors and filed on the same date. 

6 (3) STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR 

7 DEVELOPMENT 

8 _ None. 

9 | (4) REFERENCE TO AN APPENDIX 

10 U This application includes a hard copy Appendix comprising an exemplary code listing for a 

1 1 03 novel COMPOSITE SERVICE DEFINITION LANGUAGE, "CSDL." 

r — i 

12 ^ (5) BACKGROUND OF THE INVENTION 

13 M (5.1) FIELD OF THE INVENTION 

m 

14 % The present invention relates generally to electronic-commerce and electronic- 

I . s r 

15 : services and, more particularly, to a modeling tool for development of electronic-services, 

16 methodologies related to the tool, uses of the tool, and an electronic-service employing the 

17 tool. 

18 (5.2) DESCRIPTION OF RELATED ART 

19 In the state of the art, the Internet is not only being used to provide information and 

20 perform electronic commercial business transactions ((business-to-business and 

21 customer/client-to-business; hereinafter "e-commerce"), but also as a platform, or set of 

22 discrete platforms, through which services and products are delivered to businesses and 
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1 customers. (Depending on the context, "Internet" or "internet" is used herein as both a 

2 specific and generic term for any collection of distributed, interconnected networks 

3 (ARPANET, DARPANET, World Wide Web, or the like) that are linked together by a set of 

4 industry standard protocols (e.g., TCP/IP, HTTP, UDP, and the like) to form a global, or 

5 otherwise distributed, network.) The recent development of large numbers and types of 

6 electronic-services (hereinafter "e-service(s)" or "ES"), as well as of electronic-service 

7 providers, sets out a need for mechanisms and frameworks that support providers in 

8 „ developing and delivering e-service and support consumers in finding and accessing those 

EZJ 

9 ~ e-commerce businesses and any related physical business outlets. Thus, software 

10 y, vendors and industry consortia are providing models, languages, and tools for describing 

1 1 S e-services and making them available to users. Such tools and frameworks usually allow 

12 • the specification of specific e-services in terms of their inherent properties, which can be 
□ 

13 ^ generic (such as the electronic-service name and location, e.g., fictitious Acme Cars) or 

iU 

14 £ service item specific (such as the car size for a car rental service). Depending on the 

15 framework, the properties are generally represented by Java vectors or XML documents. 

16 In addition, software vendors provide software platforms ("E-Service Platform," or simply 
n "ESP") that allow service providers to register and advertise their services and allow 

18 authorized users to lookup and access registered electronic-services. 

19 FIGURE 1 (Prior Art) is a schematic representation of such a ESP system. 

20 Examples of commercially available platforms are BEA Web Logic Collaborate"", 

21 WebMethods Enterprise" 11 , Sun Microsystems Jini ,m , IBM WebSphere" 11 , and present 

22 assignee Hewlett-Packard Company's HP ,m e-speak tm ESPs 100 (further details being 
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1 available at http://www.e-speak.hp.com). Ovals 103 labeled "ES" represent specific E- 

2 Service(s) 103. An exemplary Service Provider 105, such as a public transportation 

3 related corporation, may register a plurality of generic services: buying cars, renting cars, 

4 selling cars, van or bus services, limousine services, and the like, each being a specific 

5 individual E-Service 103. An E-Service Platform 100 itself may be coupled to other 

6 platforms 101 for subsidiary or specialized E-Service(s) 103, such as those which are 

7 internal operations of the E-Service Platform related business itself. This platform 

8 O approach enables the uniform representation, search, and access of business 

M3 

9 applications, both those used for internal operations (such as access to databases or 

10 other enterprise applications and the like as would be known in the art) and the ones that 
up are made available to customers, Client 107, typically via the Internet at an Internet 

12 p address. ESPs 100, 101 typically allow Service Providers 105 to register specific 

13 W electronic-services, each represented as an ES 103 oval symbol, and allow authorized 

14 P Clients 107 to lookup and invoke registered electronic-services. In order to make 

15 electronic-services searchable and accessible to customers, Service Providers 105 (or 

16 other user in the case of a sub-platform 101) must register each service definition with an 

17 ESP 100, 101 (and possibly with other advertising services (not shown)). As part of the 

18 registration process, the Service Provider 105 gives information about each electronic 

19 service, such as the service name, the methods (operations) that can be performed on the 

20 service along with their input/output parameters, the list of authorized users, and the like. 

21 Note that an electronic-service may provide several methods (operations) to be invoked as 

22 part of its internet interface; for instance, an e-music service may allow users to browse or 
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1 search the catalog, to listen to songs, or to buy discs or downloadable mp3 files. In 

2 addition, a Service Provider 105 specifies who is the handler of the service, i.e., the 

3 application or server that must be contacted in order to request actual service executions. 

4 ("Client"-"Browser", "Server" terms are used as the standard model of interaction in a 

5 distributed computer network system in which a program at one site sends a request to 

6 another site and then waits for a response. The requesting program is called the "client," 

7 or "browser" and the program which responds to the request is called the "server.") 

8 c Depending on the service model and the ESP 100, 101, the service handler can be 

9 gg identified by providing a linking Universal Resource Indicator ("URI ") - such as in HP e- 

10 M; speak form - or by giving a proxy Java object that will take care of contacting the handler - 

11 2 such as in Jini. 

12 U Customers 1 07 may look for available electronic-services by issuing service 

13 fy selection queries that may simply search electronic-services by name or that can include 

(SS 

14 £3 complex constraints on the service properties as well as ranking criteria in case multiple 
is electronic-services satisfy the search criteria (e.g., not just Acme Car Rentals (fictitious) 

16 but Acme Car Rentals, midsize, San Jose airport, this Saturday night Service selection 

17 queries return a reference to one or more electronic-services that can be used to invoke 

18 them. 

19 The uniform representation and implementation of applications according to a 

20 homogeneous e-service framework creates a need for methods, devices, and tools for 

21 composing individual, web-accessible E-Service (possibly offered by different provider 

22 companies) into pre-packaged, value added, "composite e-service," where a composite e- 
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1 service is a service composed of more than one individual service and inherent methods 

2 thereof. For instance, a provider 105 having an appropriate tool could offer a travel 

3 reservation service by composing hotel and flight reservation services, or it could offer an 

4 itinerary planning service by composing road map services, weather services, traffic 

5 prediction services, and "utility" services to collect data from the user via the web or to 

6 send e-mail notifications. 

7 One current approach to structuring work item processes is generally referred to as 

8 "traditional subprocess" coding. Each individual context of the process has to be 

9 % maintained in ad-hoc ways by the process developer, who has to define ad-hoc variables 

10 r for this purpose. Explicit nodes of a flow diagram for such a one-level processing 

1 1 m architecture must be included in the process definition just for the sake of searching 

O 

12 h subprocesses to interact with. For complex services, process/subprocess coding is 
Q 

13 y extremely complex and necessarily proprietary to the specific service for which it was 

ry 

14 % developed. Upgrading and maintenance requires specific knowledge and understanding 

15 ' ' of the specific program. 

16 Another current approach to providing a composition facility, advocated by 

17 workflow and Enterprise Application Integration ("EAI") vendors, consists in offering a 

18 development environment targeted mainly to the enterprise's information technology ("IT") 

19 personnel. Basically, in another one-level modeling structure, a service provider specifies 

20 the flow of service invocations (i.e., the electronic-services to be invoked, their input and 

21 output data specification, and their execution dependencies). A workflow developer 

22 specifies the flow of the work, i.e., the work items to be executed (where a work item 
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1 represents the invocation of a business function and is a black box from the workflow 

2 viewpoint), their input and output data specifications, and their execution dependencies. 

3 Exemplary traditional workflow management systems such as MQ Workflow (IBM. MQ 

4 Series Workflow - Concepts and Architectures (1998)), InConcert (Ronni T. Marshak. 

5 InConcert Workflow. Workgroup Computing report, Vol. 20, No. 3, Patricia Seybold Group 

6 (1997)), or Staffware2000 (Staffware Corporation, Staffware2000 White Paper (1999)), 

7 nor among newly developed, open, XML- and web-based systems such as Forte' Fusion 

8 s (J. Mann. Forte' Fusion. Patricia Seybold Group report (1999)) and KeyFlow (Keyflow 

9 gg Corp. Workflow Server and Workflow Designer (1999)), are commercially available. 

10 U Packaged Workflow Management System (WfMS) and problems associated therewith in 

sss- 

•I I 

1 1 S3 contrast to the present invention are discussed hereinafter. 

C3 

12 JL The problem issues are similar to proprietary process/subprocess coding. To 

\\ 

13 py complicate matters even further, in the e-service virtual world, an E-Service 1 03 may have 
H q several states and several state transitions caused by any individual interaction. 

15 As shown in FIGURE 1A (Prior Art), to describe a simple generic interaction flow 

16 1 1 1 in an ad-hoc manner results in a complex, tangled spaghetti-like, workflow (even 

17 without showing in this simple example all of the subprocesses which are involved within 

18 each process node 1 1 3 and decision node 1 1 5 (and showing only successful decision flow 

19 paths)). Such one-level workflows are difficult to design and maintain. Alternatively, one 

20 must do hard-coding of the flow logic. 

21 It has been discovered by the present inventors that at a generic level an E-Service 

22 103 access requires: (1) operations to be performed at the service level (e.g., search, 
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1 authentication, service-level exceptions, and the like) and (2) operations to be performed 

2 at the interaction, or method invocation, level (e.g., the invocation of the method and the 

3 handling of method-level exceptions, and the like). Although composite electronic- 

4 services could be developed by hard-coding the business logic using some programming 

5 language, Service Providers 105 would greatly benefit from a composition tool that could 

6 ease the tasks of (1) composing E-Services, (2) managing and monitoring them, and (3) 

7 making them available to authorized service provider users. In addition to such a tool, 

8 ^ there is also need for an approach that consists in providing composition functionality as 

9 J an e-service itself (or, rather, a meta-service, since it is a service for developing electronic- 

10 ^ services); moreover, by providing a new e-service composition functionality as an e- 

11 03 service itself, the service composition facility can be advertised, discovered, delivered, 

12 - managed, and protected by end-to-end security analogously to any other e-service, 

Q 

n ~! thereby exploiting all the advantages and features provided by the ESP 100. In addition, 

tss 

14 J the ability of defining and deploying composite electronic-services is not limited to the ESP 

15 ' 100's owner, but can be offered to other providers, businesses and customers, thereby 

16 relieving them from the need of maintaining a composition system that may be onerous to 

17 buy, install, and operate. Hereinafter this meta-service e-service is referred to as 

18 Composition E-Service, or simply "CES." 

19 There is a need for the design, architecture, and implementation of a composition 

20 tools, models, and e-services for developing composite e-services. 

21 (6) BRIEF SUMMARY OF THE INVENTION 

22 The present invention provides a composition model, and associated tools and 
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1 services, for e-services. 

2 In its basic aspect, the present invention provides a model for compiling a 

3 specification of a process definition including: service nodes, wherein each of said service 

4 nodes is a representation of a consumer service; and a flow diagram sequencing said 

5 service nodes as a representation of the process definition. 

6 In another aspect, the present invention provides a computer tool for compiling a 

7 specification of a process including: computer code for representing a plurality of individual 

8 O services as service nodes, wherein each of said service nodes is representative of a 

9 ff respective service invocation setup phase for each of the individual services; and 

10 yg computer code for compiling a set of the service nodes into a composite service forming a 

CD 

1 1 u generically defined flow said process. 

12 p; In still another aspect, the present invention provides a computer tool for compiling 

13 '% a specification of a process and executing the specification of the process including: 

; j: 

14 f computer code for representing a plurality of individual services as service nodes, wherein 

15 each of said service nodes is representative of a respective service invocation setup 

16 phase for each of the individual services; computer code for compiling a set of the service 

17 nodes into a composite service forming a generically defined flow of said process; 

18 computer code for executing the specification of the process represented by the 

19 generically defined flow by expanding each node of said set of the service nodes into 

20 method nodes, invoking functionalities of the individual services thereby, wherein each of 

21 said method nodes represent a plurality of inherent executable operations associated with 

22 a respectively associated one of the individual services. 
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1 In another aspect, the present invention provides a method for structuring individual 

2 electronic services registered on an electronic service platform, the method including: 

3 providing a top level having service nodes representative of extracted common elements 

4 of the composite service; providing a subsidiary level, wherein said service nodes are 

5 expanded into method nodes for execution of specific operations inherent to a respective 

6 electronic service represented thereby; and providing linking nodes in the top level for 

7 connecting said service nodes into a process flow, wherein said flow forms a hierarchical 

8 _ specification having a sequential series of said individual electronic services. 

9 % In another aspect, the present invention provides a method of executing a given 

10 u composite process, defined as including a plurality of individual electronic services 

1 1 m registered on an electronic services platform, the method including: segregating generic 

12 ;l electronic services common to the given composite process from operations respectively 

13 ~1 inherent to each of said generic electronic services; compiling a composite process flow 

H 

14 g using said generic electronic services; and invoking each operations functionalities of each 
is' of said generic electronic services by expansion of each of said generic electronic services 

16 into said operations only as needed to continue said composite process. 

17 In another aspect, the present invention provides a computer tool for composing 

18 electronic service searching runtime criteria including: computer code for structuring a 

19 plurality of service nodes, wherein each of said service nodes is representative of a 

20 generic service and includes only those criteria essential to invoking said service; 

21 computer code for invoking a plurality of method nodes, wherein a set of method nodes is 

22 representative of operations inherent to an associated one of said service nodes; and 
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1 computer code for linking nodes sequencing said service nodes into a coherent flow 

2 representative of a composite service including more than one generic service. 

3 The foregoing summary is not intended to be an inclusive list of all the aspects, 

4 objects, advantages, and features of the present invention nor should any limitation on the 

5 scope of the invention be implied therefrom. This Summary is provided in accordance 

6 with the mandate of 37 C.F.R. 1.73 and M.P.E.P. 608.01(d) merely to apprise the public, 

7 and more ESP 100ecially those interested in the particular art to which the invention 

8 n relates, of the nature of the invention in order to be of assistance in aiding ready 

9 J understanding of the patent in future searches. Objects, features and advantages of the 



10 N= present invention will become apparent upon consideration of the following explanation 
43 

1 1 5 and tne accompanying drawings, in which like reference designations represent like 

12 e features throughout the drawings. 

13 Ji (7) BRIEF DESCRIPTION OF THE DRAWINGS 



14 p FIGURE 1 (Prior Art) is a block diagram representative of an E-Service model. 

in 

r~ 

15 FIGURE 1 A (Prior Art) is a service process diagram. 

16 FIGURE 2 is an exemplary embodiment of a two-level service composition model in 

17 accordance with the present invention. 

18 FIGURE 3 is a generic block diagram representative of a Composition E-Service 

19 model in accordance with the present invention, referencing the exemplary model as 

20 shown in FIGURE 2. 

21 FIGURE 4 is a generic block diagram representative a Composition E-Service 

22 compilation architecture in accordance with the present invention as shown in FIGURES 2 
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1 and 3. 

2 FIGURE 5 is a flow chart of a Composition E-Service compilation process in 

3 accordance with the present invention as shown in FIGURES 2 and 3. 

4 FIGURE 6 is a generic block diagram representative a Composition E-Service run- 

5 time architecture in accordance with the present invention as shown in FIGURES 2 and 3. 

6 FIGURE 7 is a flow chart of a Composition E-Service run-time process in 

7 accordance with the present invention as shown in FIGURES 2 and 3. 

8 g FIGURE 8 is a block diagram exemplifying a client use of a Composition E-Service 

9 1 as shown in FIGURES 2, 3, 6 and 7. 

10 fc* FIGURE 9 is a block diagram exemplifying provider-provider-designer 105 uses of a 
n 2 Composition E-Service as shown in FIGURES 2, 3, 4, and 5. 

12 ~ FIGURE 10 is a block diagram of components of a Composition E-Service 

M 

13 ry prototype in accordance with the present invention. 

14 Q FIGURE 1 0A is a block diagram of the architecture for registering composite e- 

15 services in accordance with the present invention as shown in FIGURE 10. 

16 FIGURE 1 0B is a flow chart of the method of updating composite e-services in 

17 accordance with the present invention as shown in FIGURE 10. 

18 FIGURE 10C is a flow chart of the method for registering composite e-services in 

19 accordance with the present invention as shown in FIGURE 10. 

20 FIGURE 1 0D is a flow chart of the method for deleting composite e-services in 

21 accordance with the present invention as shown in FIGURE 10. 

22 FIGURE 1 1 is a block diagram of invocation of composite services using the 
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1 prototype as shown in FIGURE 10. 

2 The drawings referred to in this specification should be understood as not being 

3 drawn to scale except if specifically annotated. 

4 (8) DETAILED DESCRIPTION OF THE INVENTION 

5 Reference is made now in detail to a specific embodiment of the present invention, 

6 which illustrates the best mode presently contemplated by the inventors for practicing the 

7 invention. Alternative embodiments are also briefly described as applicable. Subtitles 

8 _ used hereinafter are for reference only; no limitation on the scope or aspects of the 

9 % invention is intended nor should any be implied therefrom. 

10 u MODELING TOOL FOR THE COMPOSITION E-SERVICE (CES). 

l i 63 The present invention provides a two-level process modeling-tool 200 (also referred 

12 *_ to herein as simply the "model" or the "tool") as exemplified by FIGURE 2. The tool is 

Q 

13 y, useful to the Service Provider 105, or service provider's IT personnel, or any composite 

iy 

14 % service provider-designer; hereinafter referred to more simply and generically as the 

15 " "provider-designer 105." 

16 At a model top-level 201 , a composite service (the example is for food ordering, 
n delivery, and payment) is specified by a flow of service nodes 203 each representing the 

18 usage of a particular E-Service (e.g., the E-Services 103 (Fig. 1)). The specification, or 

19 definition, of a service node 203 includes service -level properties such as: 

20 (1) search recipes, also referred to as service selection rules, 

21 (2) authentication, 

22 (3) certification, 
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(4) service-level exception handling rules, 
and where required, 

(5) the definition of the interaction flow itself, defining how the interaction with the service 
is conducted, forming a second, or lower-level 207 of the two-level architecture model. 
Each single interaction at the model lower-level 207 is modeled by interaction, or method, 
nodes 205, 205' which are invoked from the lower-level 207. Method nodes 205, 205' are 
executed in the context of a given E-Service 200. Method nodes 205, 205' 205 can 
specify: 

(1) the service operation to call, i.e., a specific method to be invoked, 

(2) input data format, 

(3) output data format and handling, and 

(4) interaction-level exception handling rules. 

Note that this tool has exception-handling behaviors provided for at both levels, 
segregating service exception handling and interaction exception handling. 

In other words, service nodes 203 of the top-level 201 define the highest level 
definition of a service on which methods or operations of the lower level 207 can be and 
generally are invoked and performed. Service nodes 203 define the service invocation 
setup phase (e.g., search for the best service provider, authenticate, and the like) and 
method nodes 205, 205' 205 define the interaction phase, invoking actual physical 
operations (e.g., delivering goods, receiving payments, and the like). Having two different 
levels 201 , 207 and two different kinds of nodes 203, 205 provides a tool which simplifies 
the service composition effort since it allows the definition of a context - the service - in 
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1 which interactions are performed. This simplification is illustrated by comparing Fig. 2 

2 with Fig. 1 A (Prior Art), illustrating that the tendency toward the complex spaghetti-like 

3 workflow of the prior art is eliminated. The model thus provides for the design of 

4 composite electronic-services by being able to compose more basic ones, making it easier 

5 to design composite electronic-services, to maintain composite service definitions, and to 

6 manage authentication and exceptions at the appropriate level of abstraction. 

7 At the top level 200, the CES graphical construct may include service, decision, and 

8 ^ event nodes. In Fig. 2, square boxes represent service nodes 203 while diamonds 

9 ~ represent decision-route nodes 115. Service nodes 203 represent invocations of both 

10 [I basic e-services or composite electronic-services; decision-route nodes 115 specify the 

1 1 i| alternatives and rules controlling the execution flow; and, event nodes 204 (an "event 

n 

12 e_ node" is generic for a predetermined system event such as " 'WAIT' for customer 

13 y- cancellation;" an event node enables composite electronic-services to send and receive 

ru 

14 % several types of notifications (in this example, if the operation receives a "cancel order" it 

fcsr 

is ' thus leads to a process "complete" node.) A composite service instance is an enactment 

16 of a composite service. The same composite service may be re-instituted several times, 

17 and several instances may be concurrently running. For example, customers could be 

18 concurrently using a "food delivery" composite e-service. 

19 Look also to FIGURE 3, as an exemplary embodiment, a FoodOn Wheels E-Service 

20 303 advertises that it delivers any kind of food to a customer's door. FoodOnWheels 303 

21 receives order from a customer and, if the customer has a valid credit card - i.e., "Check 

22 credit" labeled service node 203 - FoodOnWheels 303 selects one or more restaurants 
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1 that can provide the requested food (unless the customer specifies a preference) by 

2 accessing a restaurant selection service - i.e., "Restaurant selection" service node 203. 

3 Then, FoodOnWheels 303 picks up the food at the restaurant(s) and delivers it to the 

4 customer at the requested time, through a food delivery service - i.e., "Wheel delivery" 

5 labeled service node 203. Note that Wheel delivery shows a lower level 207 method flow 

6 (Fig. 2, only). Next, the customer's credit card is charged, by invoking a credit card 

7 payment service - i.e., "Credit card" labeled service node 203. 

8 n Thus, in one basic aspect, the present invention is a modeling tool for constructing 

9 g3 composite-services, segregating services and methods into a two-level architecture. 

10 h COMPOSITION E-SERVICE (CES) TOOL 

n 2 As illustrated in FIGURE 3, CES 300 is a higher level abstraction imposed onto an 

12 L E-Service Platform 100. In general it allows any user, viz., provider-designer 105 to: 

13 m (1) Register and advertise definitions of composite electronic-services with the ESP 100 

14 o and make them available to authorized Clients 107 just like any other e-service (see Fig. 

15 ' 1); 

16 (2) invoke (start executions of) composite electronic-services (the CES 300 will execute 

17 the service on behalf of the user by appropriately invoking the component electronic- 

18 services as defined by the CSDL specifications); and 

19 (3) manage composite electronic-services: the CES 300 allows the modification or deletion 

20 of composite service definitions as well as running instances; 

21 (4) monitor composite electronic-services: the CES 300 allows customers and Service 

22 Providers 105 to monitor/track the execution of on-going instances as well as completed 
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1 




composite service executions. 


2 




CES 300 is not linked to a specific service composition language. It is a generic 


3 




component and in principle can accept definitions provided in any known process flow 


4 




language that composes e-services. Note that the present invention also includes a 


5 




specific Composite Service Description Language (CSDL) for defining composite E- 


6 




Services 103; CSDL features described in detail hereinafter. 


7 




More specifically, FIGURE 4 illustrates the CES-based e-service registration system 


8 


o 


architecture 400 and generalized methodology flow for a composite E-Service 200. 


9 


'J3 
M= 

tU 


(Simultaneous reference to Fig. 3 will aid in understanding.) In order to register a 


10 


composite service, a composite service provider-designer 105 must give the same 


11 


□ 


information needed to register a basic e-service to the CES 300 (except for the service 


12 




handler), so that the composite E-Service 200 can be registered and made available to 


13 


m 


authorized users. In addition, the Service Provider 105 IT personnel, or composite service 


14 


B 


designer, gives the specifications 401 (CSDL-based) to the CES's "Composite service 


15 




definition module" 300' to define how electronic-services should be composed. 


16 




For example, Fig. 3 shows the composite service registration process for a 


17 




composite E-Service 303 (analogous to ES 200, Fig. 2) called FoodOnWheels (described 


18 




in more detail below). Such a provider-designer 105 who wants to define a new composite 


19 




service invokes the register method of the CES by sending a packet 307 of the service 


20 




description (service information plus CSDL flow) as a parameter. The CES 300 then 


21 




registers 309 the composite service with the ESP 100 in order to make it available as a 


22 




specific E-Service 303 for other authorized customers, e.g., Client 107. The registration 
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1 




with the ESP 100 is analogous to any other service registrations, and therefore the CES 


2 




300 must provide all the required information describing the E-Service and restricting 


3 




access to it, placing it in an appropriate service repository, storage memory, 305. In 


4 




particular, the registration 309 should also specify who is the handler for the e-service. 


5 




COMPOSITION E-SERVICE BEHAVIOR AND USE 


6 




As shown in FIGURES 6 and 7, the run-time, or execution, architecture 600 and 


7 




flow 700 of the CES 300 is illustrated. FIGURE 8 depicts a Client 107 that needs an ES 


8 


P 


for food delivery. When a Client 107 needs a food delivery service, it queries 801 the ESP 


9 


: „ 


100, and thus the ESP 100 repository 305, to find out which electronic-services are 


10 


r~' 
Le. 

r 

• T: 


available and appropriate to the search terms. The Client 107 may ask the ESP 100 to 


11 


fr= 


rank the electronic-services according to the specified criteria and return the best one. If 


12 




the best service happens to be FoodOnWheels 300, then a reference to this service is 


13 


RI 


returned 802. As for any other service, the Client 107 can then query the service 


14 


=P 

.ESS 

u 


description stored in the repository 305 and perform 803 method invocations on this 


15 




service. Note that the process is transparent; the Client 107 has no knowledge that the 


16 




service is in fact an execution of a composition service of the CES 300 (demonstrated by 


17 




the dashed line connecting CES 300 to ESP 100). Being a composite service, Food On 


18 




Wheels is executed by the CES. Note also that in other embodiments, the composite 


19 




service may be actually executed by some other entity, possibly created by the CES or 


20 




another composite service definition. 


21 




Turning back also to Figs. 6 and 7, a composite service execution module 300" of 


22 




the CES 300 receives the request to start a composite service operation, step 701 . 
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1 Access to the composite services repository 305 provides the definition of the composite 

2 service to be executed, step 703. Based on the composite service definition, a 

3 determination of the next service node 203 to be activated is rendered, step 705. In 

4 accordance with the composite service definition, the current node's service selection rule 

5 is executed, step 707. If the execution of the current service node 203's service selection 

6 rule returns an error, decision-route node 709, a notification of an error is dispatched, step 

7 71 1 , and the operation aborted, step 713. Assuming no error occurs, authentication is 

8 performed, step 715. Assuming authentication is verified, the current service node 203's 

9 ^ method nodes 205, 205' are similarly executed, steps 717, 719. Once all top-level service 

10 M nodes 203 and lower-level method nodes 205, 205' are successfully navigated by the CES 

s 

1 1 ro 300, the composite service execution is completed and the results are returned 802 to the 

12 %. Client 107, e.g., a confirmation of the food order and payment. 

13 pi COMPOSITION E-SERVICE TOOL FUNCTIONS 

14 □ Turning to FIGURE 9, the provider-designer 105 is provided with ancillary generic 

15 functions 901 - in the art these are sometimes referred to as "primitives" - for changing and 

16 managing e-service definitions, monitoring run-time executions, obtaining analytical- 
ly statistical reports, and the like as may be pertinent to any particular implementation. This 

18 FIGURE demonstrates what happens logically as the FoodOnWheels 303 composite 

19 electronic service is not a separate entity per se; the CES 300 offers the primitives 

20 transparently to the Client 107. 

21 Note that in the preferred embodiment, the definitions of composite services are 

22 "owned" by the CES 300 as demonstrated by the model architecture of FIGURE 10A (Fig. 
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10A also relating to maintenance (see also FIGURE 10B - 10D of an already registered 
service). Note that the architecture of FIGURE 10A shows that the CES 300 is essentially 
in control of all the main functions including receiving composite service definitions, 
creating composite service definitions if so requested by a Service Provider 105 (viz., the 
meta-service described above and in more detail hereinafter), saving composite service 
definitions in a definition repository 1005, maintaining each composite service definition, 
providing monitoring feedback to the Provider, and, in one embodiment, of executing the 
service. 

Registration 

As shown in FIGURES 10A and 10C, the provider-designer 105 can send 1007 a 
pre-composed composite e-service definition 200 to the CES. The CES 300 receives, 
step 1009 the CSDL definition 200, compiles it, step 1011, and registers 1013 it (shown 
again as exemplary e-service "FoodOnWheels" 303) with the ESP 100. In the alternative, 
providing the metaservice, the CES 300 itself can create 1015 the composite e-services 
definition from a generic description provided (in any composition language), compile it, 
and register it. Note that the CES is used as a metaservice, i.e., a service for creating e- 
services, regardless of whether it is compiled in CSDL or another composition language. 

Updates/Deletions 

A provider-designer 1 05 can update or delete an e-service definition via the CES 
300, resulting in a corresponding update or deletion of the service registration on the ESP 
1 00. These functions are illustrated by FIGURES 10B and 10D, respectively. 

The updating function starts, as depicted in Fig. 10B, when a request for changes is 
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1 received 1017 by the CES 300 from the provider-designer 105. The CES recompiles 1019 

2 an updated composite service definition, storing the updated version in the CES service 

3 definition repository 1005. At the decision node 1022, if the updates required modifying 

4 the e-service registered at the ESP 100 repository 305 (e.g., change of name, operating 

5 parameters, and the like), the appropriate data is transferred 1023 to the registered 

6 version; if there are no registration changes, the flow path ends. 

7 Deletion of a service is naturally much simpler as depicted by Fig. 10D. When a 

8 a deletion request is received 1025 from the provider-designer 105, it is expunged 1027, 

9 « 1029 from both repositories 1005, 305. 

10 ,f t Monitoring/Reporting 

1 1 2 In the preferred embodiment, the CES 300 allows the Service Provider 105 to 

12 q monitor the status of service executions (note that since any composite service is itself an 

H 

13 ry e-service, monitoring features provided by CES are in addition to whatever mechanism is 

14 Q provided by the E-Service 303 platform for service monitoring). As examples, the CES 

i s 

i — 

15 300 allows the Service Provider 105 to check how many instances of its composite service 

16 are in execution, at what stage they are in the execution (i.e., which path in the execution 

17 flow they have followed, which service is currently being invoked, what is the value of 

18 composite service data, and the like), or other characteristics that may be pertinent to any 

19 particular implementation. 

20 In the preferred embodiment, E-Service 103 created by the CES 300 also includes 

21 method calls that allow Clients 107 to control service executions. More specifically, client 

22 users can pause, resume, and cancels service execution. Note that while Service 

Docket No.: 10008270-1 

-20- 




1 




Providers 105 interact with the CES 300, Clients 107 of composite electronic-services only 


2 




interact with the electronic-services through the service reference they got as a result of 


3 




the lookup, as with a basic E-Service 103 (Fig. 1). The CES appropriately creates e- 


4 




services that provide methods to control service executions. Also in the preferred 


5 




embodiment, the CES itself provides a method to invoke and control the service 


6 




executions. 


7 




Meta-Service 


8 




The CES 300 should be able to compose 1015 any service that is reachable 


9 


ys 


through the ESP 100 to which the CES architecture interconnected (sometimes referred to 


10 


r 


in the art as "on top of). Advanced ESPs 100, such as HP e-speak platforms, are 


11 


£3 


capable of searching and accessing an E-Service 103, 303 delivered through ESPs 100 of 


12 


S 


different kinds, either natively or through gateways (as described in more detail 


13 


ru 


hereinafter). Hence, the CES 300 conveniently employs the capability of the ESP 100 to 


14 


6 
5 


access E-Services 103 running on top of heterogeneous ESP 100 platforms rather than 


15 




re-developing the same interoperability features. In other words, the services that are 


16 




invoked as part of the composite service can be on any ESP; moreover, the CES can be 


17 




defined to compile both CSDL and non-CSDL specifications. 


18 




COMPOSITE SERVICE DEFINITION LANGUAGE. CSDL 


19 




The present invention also provides a service composition model language; see 


20 




also the Appendix hereto. 


21 




Turning to Fig. 5, and simultaneously referring also to Fig. 2, this compilation- 


22 




registration methodology flow 500 is shown in more detail. The CES 300 (Fig. 3) receives 
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1 




the composite service definition data, step 501 , in the form of a series of node 


2 




specifications. Taking the first node, step 503, a determination, decision node 504, is 


3 




made as to whether it is a decision-route node 1 15 or an event node 204. Whenever a 


4 




decision-route node 1 15 or event node 204 is encountered, it is compiled, step 505, and 


5 




the process then determines if there are more nodes to be processed or whether it was 


6 




the last node, decision node 507. When the last service node 203 is processed, the 


7 




compilation is finished 509, and the CES moves on to registering the E-Service (described 


8 


x~i 


hereinafter with respect to Fig. 6). As long as there are "More nodes to be processed," 


9 




the flow loops back to taking the next node definition, step 503. 


10 




Assuming now that the current node is not a decision-route node 1 15 or an event 


11 


fri 
~~ 


node 204, but is a service node 203, the attributes of the data from the provider-designer 


12 


£ 

0 


105 is verified, step 51 1 . Whenever there is any "Error detected," as illustrated by 


13 




decision-route node 512, the provider-designer 105 generating the definition is notified, 


14 




step 513, and the compilation session is aborted, step 515. Once a current node 


15 




definition 503 is verified, that definition is stored, step 517, in any known manner (depicted 


16 




as memory stack 518). 


17 




As described above, a service node 203 can define a service-inherent method(s) or 


18 




method flow (see Fig. 2, "Wheel delivery"). The CES 300 gets any "next" method node 


19 




205 within the current service node 203 just stored, step 519. The current method node 


20 




specification under analysis, e.g., Fig. 2, method node 205, is verified, step 521, and when 


21 




no error is found (decision-route node/step 522), appropriately stored in memory 518, step 


22 




523. A determination, decision-route node/step 525, is made as to whether there are 
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1 more method nodes 205, 205' within the current service node 203, e.g., Fig. 2, "next" 

2 method node 205', and if so the flow loops back to retrieve 519, verify 521 , and store 523 

3 each such next method node. Once there are "No more method nodes 205, 205' to be 

4 processed" the determination step 507 as to whether there are "More nodes to be 

5 processed," looping back to retrieving the next node, step 503, or finishing the compilation, 

6 step 509. After compilation is successful, the composite service definition is transferred to 

7 the ESP 1 00 repository 305 (Figs. 3 & 4). 

8 ra Note that the CSDL language and system of the present invention for e-service 

9 % composition has many different requirements with respect to traditional workflow 

i . a j 

10 j=& architectures. 

1 1 00 A first difference should be recognized at the level of E-Service selection. Process 

6 

12 ^_ nodes 1 13 in traditional workflow graphs as illustrated in Fig. 1A (Prior Art) represent 

13 J administrative or production work items, assigned to human or automated resources. 

14 q Often, workflow models also impose a resource model, based on roles and/or 

u 

15 organizational model levels. Selecting a resource typically involves selecting an employee 

16 or an enterprise application by means of a resource language (possibly rich and 

17 expressive) that identifies authorized resources depending on the roles they play and on 

18 the level they belong to. On the other hand, service nodes 203 in an e-service 

19 environment as illustrated in Fig. 2 represent service invocations. As part of the service 

20 node 203 definition, the provider-designer 105 specifies the service to be invoked. Thus, 

21 the e-service environment has very different concepts and requirements from the 

22 traditional workflow architecture since there is typically no fixed "organizational model" or 
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1 resource taxonomy. The E-Service 103, 303 is selected depending on its properties, and 

2 the selection criteria are specified in the query language supported by the E-Service 

3 Platform 100 (or, in general, by an e-service directory), which is usually quite powerful and 

4 flexible. The CSDL supports and facilitates the definition of service selection criteria for 

5 each node in the flow, allowing also criteria that depend on the specific instance in 

6 execution (i.e., are sensible to the instance-specific data, such as the customer name or 

7 geographical location). Following a traditional workflow approach (i.e., identify and classify 

8 □ electronic-services in advance and then specify work assignments through some role 

9 ^ expression), is not required due to the presence of a substantially homogeneously created 

10 % service repository 305 in the ESP 100 and of CSDL included service query and selection 

1 1 p language. Therefore, note that besides not being required, the traditional workflow 

E 

12 D approach is also not advised as the e-service environment is very dynamic and electronic- 
Si 

13 FU services are introduced, modified, or deleted very often; without the present invention, the 

14 P content and structure of the repository would have to be updated all the time were a 

15 traditional workflow approach employed. 

16 A second difference can be recognized with respect to input and output data. In 

17 traditional workflows, input and output data are typically specified by a set of variable 

18 names; the semantics is that the value of the input variables at the time the node 1 13 is 

19 started is passed to the selected resource, and node execution results are inserted into 

20 the output variables. Communication between a WfMS and the resources is done through 

21 adapters, that understand the syntax and semantics of the data and perform the required 

22 data mappings. E-Services 103, depending on the ESP 100 on which they run, typically 
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1 communicate in Java or XML format; these two languages dictate the rules and the syntax 

2 for data exchanges. Therefore, CSDL provides facility for processing Java and XML 

3 objects and transferring them to and from the invoked E-Service 103. Whereas in a 

4 traditional workflow approach there is a requirement to develop adapters that bridge the 

5 composition environment and each E-Service 103 to get rid of data mapping issues (at the 

6 cost of transferring the problem onto the adapters), in accordance with the present 

7 invention such adapters are eliminated. In fact, E-services 103 running on an ESP 100 

8 p share the same service model and parameter passing semantics, so that it is possible to 

i 

9 take this into account in the CES 300 model 200 and provide facility for communicating 

10 H with each of the E-Services 103 as composite pieces as prescribed by the ESP 100, 

1 1 2 thereby avoiding the need for adapters. This is a considerable advantage, given that 

12 m n developing adapters is difficult and tedious job, as demonstrated by the cost of 

13 q] commercial system integration platforms. In addition, it simplifies the use of the CES 300, 

14 p since providers-designers may define and deploy a new composite service by simply 

15 sending a single file that includes all the business logic. There is no need of changing the 

16 configuration of several different systems, as it happens with traditional workflow 

17 architectures. 

18 A third notable difference occurs with respect to consideration of the dynamic 

19 environment of e-commerce. Unlike "traditional" business processes, E-Services 103, 303 

20 have to cope with a highly dynamic environment, where new services become available on 

21 a daily basis. In order to stay competitive, Service Providers 105 should offer the best 

22 available service in every given moment to every specific Customer 107. Clearly, it is 
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1 unfeasible to continuously change a traditional workflow to reflect changes in the e- 

2 commerce business environment, since these occur too frequently whereas modifying the 

3 workflow architecture is a delicate and time-consuming activity (all spaghetti-like paths 

4 must be accounted for). Ideally, based on the modeling tool described hereinbefore, the 

5 CES 300 should be able to adapt transparently to changes in the e-commerce 

6 environment and to the needs of different customers 107 with minimal or no user 

7 intervention. 

8 p A fourth notable difference occurs with respect to the use of black boxes versus 

9 J3 multi-methods interfaces. Typically, a work item in a traditional workflow represents the 

10 *t invocation of a business function. The work item is a black box from the workflow 

ip 

ffl 

n 2j viewpoint. Instead, an E-Service 103, 303 may have several states and state transitions, 

12 q caused by method invocations. Interacting with an E-Service 103, 303 requires operations 

13 HJ to be performed at the service level (e.g., search and authentication) and operations to be 
-P 

14 P performed at the method level (e.g., method invocations). 

¥> 

is A fifth notable difference occurs at the level of security considerations. Current 

16 workflow technology has very little support for security. Often there is no encryption and 

17 access is controlled by means of user names and passwords. This is due to the genesis 

18 of WfMS as systems for managing the work in a restricted and controlled environment, 

19 generally within a corporation. In the Internet and e-service environment, the security 

20 requirements are different, and in particular E-Services 103, 303 may require the use of 

21 certificates, which therefore should be also supported by the service composition model 

22 and CSDL. 
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1 




A sixth notable difference occurs because of the nature of business-to-business 


2 




interactions. A number of standards (e.g., RosettaNef, cXML, CBL) are being defined as 


3 




industry standards or quasi-standards in order to support business-to-business 


4 




interactions, possibly limited to specific, vertical markets (such as RosettaNet for the IT 


5 




industry). Many applications that support such standards are being or have been 


6 




developed, and it is likely that many service composition applications will interact with 


7 




electronic-services that follow one of these standards. A CSDL must facilitate the 


8 


UJ 


composition of such electronic-services as well as their invocation, checking that the 


9 




appropriate protocol is followed and that exceptions are thrown out when deviations from 


10 




the protocol are recognized. 


11 


t - : 


CSDL Definition 


12 




While CSDL reuses some of the conceptualizations developed by the WfMS 


13 




provider community, it has several innovative features that make it suitable for e-service 


14 




composition. CSDL has a two-level service composition model as described hereinbefore 


15 




that distinguishes between invocation of electronic-services and of operations within a 


16 




service. This is important since some aspects of the business logic are specific to a 


17 




service and need to be specified at the service level, while others are instead specific to 


18 




each method invocation, as detailed in the following: 


19 




(1) CSDL allows the definition of how to send XML documents as input to service 


20 




invocations, and of how to map XML results into composite service data items; this is 


21 




important since most of the interactions among E-Service 103, 303 occur in the form of 


22 




XML documents; 
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1 (2) a flexible mechanism to handle certificates is provided, to enable the definition of 

2 which certificates should be sent to a service; 

3 (3) a number of adaptive and dynamic features are provided, to cope with the rapidly 

4 evolving business and IT environment in which E-Service 103, 303 are executed; 

5 (4) facilities for business-to-business interactions are provided in the form of service 

6 templates that can be reused by composite e-service providers-designers 105, so that 

7 they do not need to be concerned with technical details about the standard; and 

8 ? (5) the entire business logic can be defined within a single XML document, thereby 

y3 

9 ^ making easy and practical to provide and use composition as an e-service. 

10 g3 Operational Overview 

m 

1 1 □ A CES meta-service is described as a service that composes other basic or 

= 

12 H composite electronic-services. Such a metaservice solves the problems of advertising, 

13 *Z discovering, delivering, managing, and protecting the novel e-service, providing end-to-end 

Q 

14 security, wherein the features provided by established ESPs 100 can be used. The 

15 availability of such a meta-service frees provider organizations from the need for 

16 maintaining a proprietary IT capability for e-service composition themselves (onerous to 

17 buy, install, and operate). In other words, the present invention also includes providing a 

18 metaservice of providing composition functionality as an e-service itself. The 

19 representations and implementation of applications according to an e-service platform 

20 framework or architecture creates the opportunity for composing individual, internet- 

21 accessible e-services that are offered by different companies into pre-packaged, value- 

22 added, composite e-services. A composite e-service can be textually specified by, for 
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1 example, a known manner XML document. A composite e-service specification includes 

2 the definition of input, output, and local data items (sometimes also called flow variables), 

3 Input data items are parameters passed to the composite e-service at activation time. 

4 Output data items represent data returned to the caller at service completion. Input and 

5 output data items can also be used for routing purposes within composite e-service 

6 execution and for transferring data among service nodes 203. Local data items are 

7 neither input nor output, but are only used within the composite e-service to perform 

O 

8 ,n routing decision or to transfer data among nodes. The types of variables can be any basic 

9 u Java type (e.g., String or Integer), a Java Vector, a generic Object, or an XML document. 

10 *0 Each composite service instance has a local copy of the flow variables. 

.CCS. 

11 ^ Security 

12 ^ Besides the flowchart as in Fig. 2 that defines the flow of service invocations, the 

fii 

13 ^ definition of the composite e-service also includes security-related specifications. In 

G 

14 u particular, the definition of a composite e-service includes information about the 

is authentication certificates (such as those defined by the X.509 industry standard) to be 

16 used throughout the flow within service invocations in cases the ESP 100 and the invoked 

n e-service support or even require the use of digital certificates. By default, the CES 300 

18 invokes component services with the privileges (i.e., the certificate) of the composite e- 

19 service provider-designer 105. However, the provider-designer 105 may specify that 

20 services should be invoked with the privileges of the composite e-service users, or with the 

21 privileges specified by the content of a flow variable (for instance, the certificate to be used 

22 may be passed to the composite service as one of its input parameters). 
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1 Service nodes 203 

2 Service nodes 203 represent invocations of a given service. The E-Service 103 to 

3 be invoked is specified by a search recipe, or service selection rules, defined in the query 

4 language supported by the ESP 100. As a service node 203 is started, the search recipe 

5 is executed, returning a reference to a specific service. Recipes can be configured 

6 according to the specific service instance in execution: every word in the search recipe 

7 that is preceded by a percentage sign "%" is expected to be a reference to a flow variable, 

8 _ and will be replaced by the value of that variable at the time the service node 203 is 



9 % started. This allows the customization of the search recipe according to the value of flow 

10 y, variables. Note that different activations of a service node 203 may result in the selection 



1 1 m of different e-services. However, sometimes the provider-designer 105 needs to specify a 

12 s service node 203 that should reuse the same service invoked by another service node 

13 J{ 203. The composition service model allows this by enabling the definition of a Service 
u % Reuse attribute, or service reuse clause, that includes the name of the service node 203 

5 

15 * whose service reference is to be reused. 

16 The definition of the service node 203 may include the certificate to be used when 

17 invoking the service's methods 207. The definition at the service level overrides the one 

18 done at the top level, i.e., composite service. Since it is assumed that all invocations on 

19 the same service will use the same certificate, there is no provision for the definition of a 

20 certificate at the method invocation level. 

21 Flow of method invocations 

22 E-Services 103, 303 in most ESP 100 models, will have an interface that allows 
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1 




several operations to be invoked on them. In order to achieve their goals, Clients 107 of 


2 




these electronic-services will typically have to invoke several operations (i.e., call several 


3 




methods) on the same service. Correspondingly, CSDL allows the provider-designer 105 


4 




to specify, within a service node 203, the flow of method invocations to be performed on a 


5 




service. For instance, in accessing an e-music service, specifying a search for a given 


6 




song (invoking the search method) and, if the price for the disc that includes the song is 


7 




lower than a limit, then buying the whole disc (buyDisc method), otherwise simply 


8 




download an mp3 file of that song only, paying the requested fee (BuySong method). To 


9 




simplify both the language and the implementation, the method flow is specified with the 


10 


l.e_ 


same syntax (and semantics) of the top-level flow of electronic-services, with the only 


11 


f?i 

PI 

■car 


difference of concern being with the flow of method nodes 205, 205' instead of service 


12 




nodes 203. If only one method needs to be invoked, then the provider-designer 105 


13 


R ; 


needs not specify the flow structure, but only a single method node. In addition, CSDL 


14 


Q 


allows the definition of service nodes 203 that have no method nodes 205, 205' inside. In 


15 




fact, in a few cases, the provider-designer 105 might only want to execute a search recipe 


16 




and get the results, possibly without invoking any method on the selected service. For 


17 




instance, a node may simply need to get an e-service name, or other designator, in order 


18 




to pass it to another e-service for handling. 


19 




Method nodes 205. 205' 


20 




A method node (1) defines the method to be invoked on a service and its input 


21 




data, (2) how to handle the reply (and specifically how to suitably map the reply message 


22 




into flow variables), and (3) how to handle exceptions that may occur during the method 
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1 invocation. The name of the operation to be invoked can be statically specified, or it can 

2 be taken from the value of a flow variable; for instance, specified by a string preceded by 

3 the percentage sign, %. The input data to be sent to the method are specified by a list of 

4 variable names or values. In case of variable names, the value of the variable at the time 

5 the node is started is sent as input to the method. 

6 If a method invocation on a service returns a result (e.g., an integer or an XML 

7 document), then the provider-designer 105 needs to specify how information in the 

8 o document can be extracted and inserted into flow variables. In case the method output is 

sss. 

iU 

9 p a Java object (basic or complex), then the mapping is simply specified by describing the 

5 

10 *t name of the flow variable to which this value should be copied. For example, method 

fri 

1 1 g "CheckCredit" node of FIG. 2 returns a Boolean value defining whether the credit check on 

12 p the customer is positive or negative. In CSDL, this is defined as follows: 

sj 

13 ru <Method-Output> 

f 

14 y <Var-Mapping Flow-Var="Confirmation" /> 

15 </Method-Output>. 

16 Since it is likely that most of the output data will be a string containing an XML 

17 document, CSDL provides support for XML, and in particular it allows the provider- 

18 designer 105 to specify how fragments of the XML output document can be mapped into 

19 flow variables. A flow variable name assumes the value identified by an XSLT 

20 transformation or an XQL query on the output document. In the case of XQL queries, if 

21 the flow variable is of type XML, then the XQL query may actually return a set of elements, 

22 or a document. Otherwise, CSDL requires the query to identify a single element or 
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1 attribute, or an exception is raised. For instance, the following mapping specifies that the 

2 XQL query: 

3 customerList/customer[0] 

4 should be applied to the method output, and the result of the query should be put into 

5 variable "customer": 

6 <Method Output> 

7 <Var-Mapping Flow-Var-'customer" 

8 p Conversion-Rule= lf customerList/customer[0]" 

9 S Rule-Type="XQL" /> 

10 \* </Method Output> 

1 1 2 Tne definition of the query may be static or may include references to flow variables, as 

12 L usual preceded by the percentage sign. Note that an analogous approach can be used 

n fy with any XML query and transformation language 

14 p A COMPOSITION E-SERVICE 300 PROTOTYPE. 



15 This section presents a CES 300 prototype, for composing an HP e-speak E- 

16 Service 103, 303. The same design can however be adopted for any other ESP 100. The 

17 prototype is built as a higher level architecture of a commercial workflow engine (and 

18 specifically, for this embodiment, of HP Process Manager) that handles the execution of 

19 the flow. Note that using a commercial workflow engine does not rule out the possibility of 

20 developing a proprietary engine. FIGURE 10, components of a CES prototype 301 , 

21 showing also how the components of the prototype handle composite E-Service 

22 registrations. 
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1 A component of the CES architecture is the "gateway" 1001 that enables the 

2 interaction between a workflow engine 1003and the ESP 100. The provided gateway 

3 1001 performs appropriate mappings and implementations of CSDL semantics that is not 

4 supported by the workflow engine 1003, as discussed below. 

5 The CES front-end responds to calls from Service Providers 105 and Clients 107 

6 (even if the latter are unaware of the fact that they are communicating with the CES 300). 

7 When a Service Provider 105 registers a service, the CES front-end first translates the 

8 ^ composite service definition(s) into the language of the selected workflow engine 1 003. 

9 % The translation generates a process where nodes correspond to method invocations on 

10 J the ESP 100 or on the selected E-Service 103, 303. However, a service composition 

1 1 jjjj language can be richer than traditional workflow languages; thus, the translation can be a 

d 

12 ■ fairly complex procedure and may require the insertion of several "helper" nodes and data 

13 i J items that, in conjunction with the operations performed by the gateway 1001 (that has 

i T=r 

14 % knowledge of the semantics of such helper nodes), enable the correct implementation of 

15 r ~ the CSDL semantics. Examples of issues to deal with in the translation include: 

16 (1) mapping the two-level (service and method) model into a single-level one (in other 

17 words, the difference is that the user does not see the "spaghetti-like" workflow which is 

18 now managed by the CES, hiding the complexity from the user) and 

19 (2) rewriting the input and output data items of nodes so that they can have all the 

20 information required to build XML documents and to map back XML replies into process 

21 data. 

22 Consider, for example, the single problem of mapping the CSDL two-level service 
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1 model into a traditional workflow model. In order to map a service node 203, we need to 

2 insert a node that implements the search recipe (i.e., sends the sen/ice selection query to 

3 the ESP 100), and to define the data items needed for storing and sending certificate 

4 information. In addition, different method invocations occur in the context of the same 

5 session with the e-service. Hence, we need to define and properly initialize process data 

6 items that can carry session identifications from node-to-node. Note that this problem 

7 could not have been solved by simply defining a subprocess, both because the need for 

8 O defining service selection nodes and certificate nodes still remain, and because nodes in a 

9 subprocess do not have access to the variables of the main process (unless they are 

10 ,n passed as input parameters, but even in that case the parameters are passed by value 

69 

1 1 E and not by reference). Where it is not possible to map appropriately, part of the semantics 

£ 

12 P is encoded in the gateway 1 001 ; for instance, XQL queries are performed by the gateway 
M 

13 Ty 1001. The gateway 1001 is also in charge of replacing references to flow variables in XML 

14 y documents (i.e., those items preceded by the "%" symbol) with the actual value. 

15 After the mapping has been completed and the process is installed on the workflow 

16 engine 1003, the CES 300 registers the new service (e.g., "FoodOnWheels" 303) with 

17 the HP e-speak ESP 100. As Fig. 10 shows, the CES 300 itself is the handler for the 

18 newly registered service. However, this does not change the validity of the scenario 

19 depicted in Figs. 2 and 8. As shown in FIGURE 11, Clients 107 simply communicate with 

20 the E-Service(s) 1 1 303, 1 1 303', 1 303" through the reference they get on their browser; 

21 they are not concerned with how the service is implemented on the server side. When a 

22 Client 107 invokes a composite service, the CES 300 starts the corresponding process in 
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the flow system (the mapping between the composite e-service name and the process 
name is defined at registration time and stored within the CES). Activities in the flowchart 
200 include method invocations 207 on a given service involved in the composition. From 
a flow perspective, all activities are assigned to the gateway 1001 . The gateway 1 001 
receives indication of what to do by the workflow engine 1003 as part of the activity 
definition, along with data items that provide (a) context information about the service on 
which method calls are being or have to be placed (e.g., service references, search 
recipes, certificates, and mapping information to process the XML document returned by 
the method and update the value of flow variables) and (b) the value of the parameters to 
be passed as part of the method invocation. When the gateway 1001 receives work by 
the engine 1003, it activates a new thread in order to process the work. The thread waits 
for the reply from an E-Service 11303, 11303', 11303", executes the mapping rules, and 
sends the results back to the engine. All the state information is maintained by engine, 
and the gateway 1001 does not persist anything (this choice is motivated by the fact that 
the engine logs all state changes, so there is no need for a persistent gateway). 

The foregoing description of the preferred embodiment of the present invention has 
been presented for purposes of illustration and description. It is not intended to be 
exhaustive or to limit the invention to the precise form or to exemplary embodiments 
disclosed. Obviously, many modifications and variations will be apparent to practitioners 
skilled in this art. Similarly, any process steps described might be interchangeable with 
other steps in order to achieve the same result. The embodiment was chosen and 
described in order to best explain the principles of the invention and its best mode 
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1 practical application, thereby to enable others skilled in the art to understand the invention 

2 for various embodiments and with various modifications as are suited to the particular use 

3 or implementation contemplated. It is intended that the scope of the invention be defined 

4 by the claims appended hereto and their equivalents. Reference to an element in the 

5 singular is not intended to mean "one and only one" unless explicitly so stated, but rather 

6 means "one or more." Moreover, no element, component, nor method step in the present 

7 disclosure is intended to be dedicated to the public regardless of whether the element, 

8 ,5 component, or method step is explicitly recited in the following claims. No claim element 

9 u herein is to be construed under the provisions of 35 U.S.C. Sec. 112, sixth paragraph, 

10 e unless the element is expressly recited using the phrase "means for. . and no process 

1 1 O step herein is to be construed under those provisions unless the step or steps are 

12 ^ expressly recited using the phrase "comprising the step(s) of. . .." 

ru 
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